Summary

• handle_scheduling_update() unconditionally unscheduled and rescheduled flows even when the incoming config was identical to what was already set
• This reset the Action Scheduler timer and set first_run to now(), triggering an immediate run
• On Mar 16-17, this caused the agent ping flow (every_3_days) to fire 3 times in 7 hours instead of once every 3 days

Root cause

Any code path that calls UpdateFlowAbility with scheduling_config included — even with identical values — would:

1. as_unschedule_all_actions() — kill the existing schedule
2. as_schedule_recurring_action(time() + stagger, ...) — create a new one starting from now
3. Update first_run in the DB to the new timestamp

There was no check to see if the schedule was already set to the requested interval.

Fix

Adds scheduling_unchanged() private method that compares the incoming scheduling fields against the current DB values:

• Recurring: compares interval key (e.g. every_3_days)
• Cron: compares cron_expression string
• One-time: compares timestamp
• Manual → manual: always a no-op

If nothing changed, handle_scheduling_update() returns true early without touching Action Scheduler.

Impact

• Fixes spurious flow re-fires when flows are updated without changing their schedule
• No impact on intentional schedule changes — those still unschedule/reschedule normally
• No impact on flow creation — new flows have no current scheduling to compare against